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Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document was prepared by the authors on behalf of the Internet 
Architecture Board (IAB). It is offered by the IAB to stimulate 
discussion. 


There has recently been considerable discussion on two topics: 
MultiProtocol approaches in the Internet and the selection of a next 
generation Internet Protocol. This document suggests a strawman 
position for goals and approaches for the IETF/IESG/IAB in these 
areas. It takes the view that these two topics are related, and 
proposes directions for the IETF/IESG/IAB to pursue. 


In particular, it recommends that the IETF/IESG/IAB should continue 
to be a force for consensus on a single protocol suite and internet 
layer protocol. The IETF/IESG/IAB should: 


- maintain its focus on the TCP/IP protocol suite, 


- work to select a single next-generation internet protocol and 
develop mechanisms to aid in transition from the current IPv4, 
and 


- continue to explore mechanisms to interoperate and share 
resources with other protocol suites within the Internet. 


1. Introduction 


The major purpose of the Internet is to enable ubiquitous 

communication services between endpoints. In a very real way, the 
Internet IS inter-enterprise networking. Therefore, the issue of 
multiprotocol Internet is not just the issue of multiple network 
layers, but the issue of multiple comparable services implemented 
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over different protocols. 


The issue of multiprotocol Internet is multidimensional and should be 
analyzed with respect to two simultaneous principles: 


- It is desirable to have a single protocol stack. The community 
should try to avoid unconstrained proliferation of various 
protocol stacks. 


- In reality there will always be more than one protocol stack. 
Presence of multiple network layers is just one of the 
corollaries of this observation, as even within a single 
protocol stack, forces of evolution of that stack will lead 
to periods of multiple protocols. We need to develop 
mechanisms that maximize the services that can be provided 
across all the protocol stacks (multiprotocol Internet). 


2. Background and Context 
2.1. The MultiProtocol Evolutionary Process 
In an IAB architectural retreat held in 1991 [Cla91], a dynamic view 


of the process of multiprotocol integration and accommodation was 
described, based on the figure below. 
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Figure 1: MultiProtocol Evolution Process 
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The figure describes the process from the perspective of a community 
working on a single primary protocol suite (such as the IETF/IESG/IAB 
working on the TCP/IP protocol suite.) (Note: It must be kept in mind 
throughout this paper that, while the discussion is oriented from the 
perspective of the IETF/IESG/IAB and the TCP/IP protocol suite, there 
is a complementary viewpoint from the perspective of each of the 
communities whose primary focus is on one of the other protocol 
suites.) There are other protocol suites (for example, IPX, OSI, 
SNA). Although the primary emphasis of the community is developing a 
system based on a single set of protocols (protocol suite), the 
existence of other protocol suites demands that the community deal 
with two aspects of multiprotocolism. The first is interoperability 
between the primary protocol suite and other protocol suites. The 
second is resource sharing between the primary protocol suite and 
other protocol suites. Both interoperability and sharing may happen 
at multiple levels in the protocol suites. 


Achieving interoperability and resource sharing is difficult, and 
often unanticipated interactions occur. Interoperability can be 
difficult for reasons such as lack of common semantics. Resource 
sharing can run into problems due to lack of common operational 
paradigms. For example, sharing bandwidth on a link may not work 
effectively if one protocol suite backs off in its demands and the 
other does not. Interoperability and resource sharing both require 
cooperation between the developers/users of the different protocol 
suites. The challenge in this area, then, is to develop mechanisms 
for interoperability and resource sharing that have minimal negative 
affect on the primary protocol suite. 


The very attempts to achieve interoperability and resource sharing 
therefore lead to an attempt to bring the multiple protocol suites 
into some level of harmonization, even if it is just to simplify the 
problems of interoperability and sharing. Furthermore, the 
communications between the communities also leads to a level of 
harmonization. These processes, together with the normal process of 
evolution, lead to changes in the primary protocol suite, as well as 
the other suites. 


Thus, the need for new technologies and the need to accommodate 
multiple protocols leads to a natural process of diversion. The 
process of harmonization leads to conversion. 


While this discussion was oriented around the relation between 
multiple protocol suites, it can also be applied somewhat to the 
process of evolution within the primary protocol suite. So, for 
example, as new technologies develop, multiple approaches for 
exploiting those technologies will also develop. The process then 
hopefully leads to a process of harmonization of those different 
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approaches. 
2.2. The Basis of the Internet 


The rapid growth of the Internet has resulted from several forces. 
Some of them are "practical", such as the bundling of TCP/IP with 
Berkeley Unix and the early decision to base NSFNet on TCP/IP. 
However, we believe that there is a more fundamental reason for this 
growth. The Internet (and the TCP/IP protocol suite) were targeted at 
Inter-Enterprise Networking. Although the availability of TCP/IP on 
workstations and the desire to have a single environment serve both 
intra- and inter-enterprise networking led to the use of TCP/IP 
within organizations, the major contribution of the Internet and 
TCP/IP was to provide to user communities the ability to communicate 
with other organizations/communities in a straightforward manner 
using a set of common and basic services. 


Fundamental to this ability was the fact that the Internet was based 
on a single, common, virtual network service (IP) with a supporting 
administrative infrastructure. This allowed a ubiquitous underlying 
communication infrastructure to develop serving the global community, 
upon which a set of services could be provided to the user 
communities. This also allowed for a large market to develop for 
application services that were built upon the underlying 
communications. 


An important corollary to having a single common virtual network 
service available to the end user (open network service) is that the 
selection of applications becomes the province of the end-user 
community rather than the intermediate network provider. By having 
this common underlying infrastructure, user communities are able to 
select their desired/required application services based on their 
unique needs, with assurance that the intermediate networking service 
will support their communication requirements. We believe that this 
has been of considerable importance in the success of the Internet. 


In addition to providing network layer services for TCP/IP transport 
layer and applications, IP may be used to provide network layer 
services for non-TCP/IP transport layer and applications. Such use is 
clearly beneficial, since it allows preservation of all the benefits 
of a single, common, virtual network service (IP), while at the same 
time widening the set of applications available to the end users. 


3. Directions for Multiprotocolism 
Over the past few years, with the increasing scope of the Internet, 


has come an increasing need to develop mechanisms for accommodating 
other protocol suites. Most techniques have fallen into the regime of 
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either interoperability (techniques that allow for communications 
between users of different protocol suites) or resource sharing 
(allowing common resources such as links or switches to jointly 
service communities using different protocol suites.) It must be 
noted that such techniques have been quite limited, with 
interoperability happening primarily at application layers and 
resource sharing happening to limited extent. 


This need to deal with multiple protocol suites has led to discussion 
within the community concerning the role of the IETF/IESG/IAB 
regarding the TCP/IP protocol suite versus other protocol suites. 
Questions are asked as to whether the TCP/IP protocol suite is the 
sole domain of interest of the IETF/IESG/IAB or if the community 
needs also to deal with other protocol suites, and if so, in what 
manner, given these other protocol suites have their own communities 
of interest pursuing their development and evolution. 


The answer to this question lies in understanding the role of the 
IETF/IESG/IAB with respect to the process described above (Figure 1). 
The continued success of the Internet relies on a continued strong 
force for convergence, making sure that the primary protocol suite 
(TCP/IP) is successful through an evolutionary process in 
accommodating both the changing user requirements and emerging 
technologies. 


Since this process requires a continued effort to accommodate other 
protocol suites within the overall Internet, efforts at 
interoperability and sharing must continue. Thus, we can summarize 
the directions for the IETF/IESG/IAB as two-fold: 


- Have as a primary focus the evolution of the primary protocol 
suite (TCP/IP), acting as a force for convergence at all times 
towards a single set of protocols, and 


- Make provision for other protocol suites within the global 
Internet through mechanisms for interoperability and resource 
sharing. 


4. Next Generation Internet Protocol 


The principles described above for multiprotocolism can also be 
applied to the discussions regarding the next generation internet 
protocol. Currently, there are several candidates for IPng, which 
raises the question of how to deal with multiple protocols at that 
level. We note that even if just one is selected, there is an issue 
involved in transitioning from IPv4 to IPng. 
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Selection of a single Internet protocol is not the only way of 
dealing with this issue. Even if a layer of ubiquity is required 
(such as that provided currently by IP), we might consider providing 
ubiquity at a different layer. For example, we could imagine having a 
common transport protocol running over multiple internet protocols. 
We also could imagine achieving interoperability by use of common 
application services (such as directory services) running over 
diverse communication services (both transport and network layers). 


These alternatives do not provide the considerable benefits of a 
single internet protocol, and therefore would be undesirable. Having 
a single internet protocol provides a common communication 
infrastructure across the various networks, thereby achieving the 
following: 


- Communities of end users can select their desired applications, 
independent of the technologies used to support the intermediate 
networks. 


- The common underlying infrastructure provides a common 
marketplace upon which application developers can create new and 
exciting applications. Installation of these applications does 
not require end users to select a corresponding network protocol 
(although some advanced applications may require enhancements, 
such as high-bandwidth approaches). 


Thus, the community (IETF/IESG/IAB) should continue to act as a force 
for convergence by selecting a single next generation Internet 
protocol and developing methods to ease the transition from IPv4 to 
IPng. Specifically, at the applications layer, it is desirable to 
promote different approaches and "let the marketplace decide." 
However, it is unacceptable to treat the internet protocol layer in 
the same way. 


5. Conclusion 


Historically, the IETF/IESG/IAB has acted as a strong force for the 
development of the Internet by acting as a force for convergence on 
and evolution of a single primary protocol suite. This has served 
the community well, and this approach should be continued for the 
future. In particular, the IETF/IESG/IAB should: 


—- maintain its focus on the TCP/IP protocol suite, 
- work to select a single next-generation internet protocol and 


develop mechanisms to aid in transition from the current IPv4, 
and 
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- continue to explore mechanisms to interoperate and share 
resources with other protocol suites within the Internet. 
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